fix(self-hosting): pass CAP_CHROME_EXTENSION_ID through to the web container (#1993)#2035
fix(self-hosting): pass CAP_CHROME_EXTENSION_ID through to the web container (#1993)#2035DPS0340 wants to merge 1 commit into
Conversation
…ntainer The extension auth endpoint requires a pinned extension id on any reachable deployment — without one it rejects every redirect URI, since an unpinned id would let any installed extension mint auth keys for a signed-in user. The variable existed in the env schema but was never mapped into cap-web in either compose file, so self-hosters had no supported way to set it and extension login always failed with a 400. Document it alongside the other optional integrations.
|
@tembo please review |
|
Heads-up on CI: the That matters more than usual for this change, because I verified locally what I could — both files parse as valid YAML and the key resolves to (The red |
|
@tembo please review |
|
@richiemcilroy — #1992 by @jerryno6 already does this, 16 days before mine. Please take theirs. The core addition is byte-identical: + CAP_CHROME_EXTENSION_ID: ${CAP_CHROME_EXTENSION_ID:-}in both Closing in favour of #1992. If it's useful once that lands, the This is the fourth overlap in my batch (#2029, #2031, #2040, this). All four trace to the same skipped check, and I've now run it properly across all nine: #2030, #2032, #2034, #2036, #2038 are the ones with no functional overlap. #2036 shares the two compose files textually — it passes AI provider keys ( |
|
Closing as promised — #1992 by @jerryno6 covers this and got there first. No action needed from anyone; I'm removing it from the review queue rather than leaving it sitting as something you'd have to diff and dismiss. Nothing here is lost: if any piece turns out to be worth having after #1992 by @jerryno6 lands, I'll send it as a small follow-up against that. |
1 participant
Fixes #1993.
Problem
CAP_CHROME_EXTENSION_IDis declared in the env schema (packages/env/server.ts:82) and is load-bearing for extension login, but it is not mapped into thecap-webservice in either compose file. Self-hosters have no supported way to set it, so extension login always fails.The failure is not a soft one.
validateExtensionRedirectUri(packages/web-backend/src/Extension/Http.ts) only tolerates an unpinned extension id on localhost:That check is correct and I have deliberately not touched it — the comment above it explains why, and it's right: without a pinned id, any installed extension could mint auth keys for a signed-in user. The bug is purely that a self-hosted deployment has no way to satisfy it, so every redirect URI is rejected with the
400the reporter saw.Fix
Three mechanical additions, no logic changes:
docker-compose.yml— passCAP_CHROME_EXTENSION_ID: ${CAP_CHROME_EXTENSION_ID:-}tocap-web, matching how the other optional integrations (GOOGLE_CLIENT_ID,APPLE_CLIENT_SECRET,RESEND_API_KEY) are wired.docker-compose.coolify.yml— same.docker-compose.coolify.env.example— a documented, empty entry so it's discoverable.Plus a Chrome Extension section in
self-hosting.mdx, next to the existing Google/Apple OAuth sections, explaining what the value is, why it's required, and where to find it.Defaulting to empty (
:-) keeps the current behaviour for anyone not using the extension: the var stays unset, the schema treats it asoptional(), and nothing changes.Notes
I left
docker-compose.template.ymlalone — it's a minimal template that doesn't carry the OAuth or Resend vars either, so adding just this one would be inconsistent with its scope.Verification
Diff: 4 files, +29/-0.